[レポート]Deep dive ハイブリッドクラウドでのDNS #NET410 #reinvent

本記事は、AWS re:Invent 2019 のセッション「Deep dive on DNS in the hybrid cloud」のレポートです。

AWS re:Invent 2019

#レポート

#AWS

坂巻一義

2019.12.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

本記事はAWS re:Invent 2019のセッション「Deep dive on DNS in the hybrid cloud」のレポートです。

概要

日本語訳

Amazon Route 53 リゾルバーエンドポイントと転送ルールの開始により、特にハイブリッドクラウド環境でDNS解決を管理するためのさまざまなエキサイティングな新しいオプションが開かれました。このセッションでは、Route 53 リゾルバーの設計を深く掘り下げる前に、製品の概要を簡単に説明します。これには、Route 53プライベートDNSを補完する方法や、可用性とパフォーマンスを達成するためのベストプラクティスが含まれます。また、AWS Transit Gateway、AWS PrivateLink、Microsoft Active Directory用AWS Directory Serviceなどのサービスで新たに出現しているいくつかの新しいパターンにも飛び込みます。

原文

The launch of Amazon Route 53 Resolver endpoints and forwarding rules has opened up a variety of exciting new options for managing DNS resolution, especially in hybrid cloud environments. This session gives a quick overview of the product before taking a deep dive into the design of Route 53 Resolver, including how it complements Route 53 private DNS and best practices to achieve availability and performance. We also dive into some new patterns that are emerging with services such as AWS Transit Gateway, AWS PrivateLink, and AWS Directory Service for Microsoft Active Directory.

スピーカー

Gavin McCullagh - Principal System Development Engineer, Amazon Web Services

レポート

アジェンダ

VPC Route 53リゾルバー
ハイブリッドクラウド
Route 53 リゾルバーインバウンドエンドポイント
Route 53 リゾルバーインバウンドエンドポイント & ルール
Route 53 リゾルバー & Active Directory
Managing DNS across many VPCs

レポート

VPCのRoute 53リゾルバー

Route 53 リゾルバーとは

VPC内外に多くのリゾルバーが存在しているが名前がなかった
- EC2 DNSリゾルバーには正式名が必要
Route 53 リゾルバーは以下としても知られている
- AmazonProvidedDNS
- VPC リゾルバー
- +2 リゾルバー
- .2 リゾルバー
- EC2 DNS Resolbver
2018年第4四半期の機能追加で正式名称が必要
- リゾルバーエンドポイント
- リゾルバー fowarding rules

VPCのDNS解決（DNS Resolution）を有効にしている場合、AmazonProvidedDNSが利用され、アドレスはVPCのCIDRに2を追加したもの。 それはS3ゲートウェイエンドポイントのようなものだが、リクエスト元インスタンスと共に、サブネット内に存在している。 VPC内からの名前解決のリクエストはマルチテナントの共有リゾルバサービス(Route 53 リゾルバー)に移動する。

Route 53 リゾルバーは、最初のクエリをチェックし、Route 53 Private DNSに送信される。

Route 53 Private DNS：どのように機能するか？

Route 53 リゾルバーは、Route 53 Private DNSのプライベートホストゾーン（PHZ）にアソシエーションする
ネームがPHZに存在する場合、クエリをRoute 53プライベートDNSに送信
Private DNSはVPC DNSレコードよりも優先度が高い
"."というゾーンを作成すると、すべてのパブリックおよびVPC DNSがオーバーライドされる

プライベートDNS - 重複ゾーンのサポート

2019年11月にリリース
プライベートDNSが重複するプライベートゾーンをサポート
1つのVPC(PHZ)でmycompany.comおよびservice.mycompany.comが可能

VPC DNS

定義済みの特別な名前空間
例
- eu-west-2.compute.intenal
- 10.in-addr.arpa...
サーバはロンドンにあるインスタンス

Route 53 リゾルバー(VPC+2)

シンプルな機能（意図して）
スケーラブル
フォールトトレラント
- 各AZで独立して動作
パフォーマンス
- キャッシュによる待ち時間が改善
リクエスト料金なし

ハイブリッドクラウド

VPCとオンプレをDX接続してる構成があったとして、オンプレ上からは、リゾルバー(VPC+2)に接続できない（=Route 53 リゾルバーに接続不可）ので、DNSフォワーダー（インスタンス）を構築しリゾルバー(VPC+2)を通し、Route 53 リゾルバーに照会。

DNSフォワーダー（インスタンス）：良い

VPCとオンプレミスDNSを統合
コスト
- VPC間で再利用可能
パフォーマンス
- キャッシュによる待ち時間が改善
フレキシブル
- ロギング、RPZ、AXFR

DNSフォワーダー（インスタンス）：チャレンジ

自前で構築
- それなりの難易度
制限
- ENI Limitはボトルネックになる可能性がある
失敗
- インスタンス障害がVPC全体に影響する
分離
- AZ障害はVPC全体に影響を与える可能性ある

Route 53 リゾルバーエンドポイント

Route 53 リゾルバーインバウンドエンドポイント

オンプレミスのリゾルバーにRoute 53 リゾルバーへのクエリを許可する
AWS Direct ConnectまたはVPNを介して到達可能なVPCでルーティング可能なENIを作成する
1つのエンドポイント = 複数のENI
制限：10,000 QPS pre ENI

インバウンドエンドポイント：ベストプラクティス

高可用性のためにマルチAZで複数のENIを使用
オンプレミスのDNSリゾルバーで再試行を使用
IPを指定
QPSのCloudWatchアラーム
EC2インスタンスは、インバウンドエンドポイントではなくVPC + 2リゾルバーを使用

インバウンドエンドポイント：複数のVPC

複数のVPCに複数のエンドポイントが必要か？

いいえ(一般的に)
- すべてのプライベートホストゾーンを1つのVPCに関連付ける
- 内部インスタンス名はすべてのVPCで解決する
- パブリックEC2の内部IPは、ピアリング/ TGWで解決

Route 53 リゾルバーインバウンドエンドポイントルール

Route 53 リゾルバーアウトバウンドエンドポイント

DNSリゾルバーを照会するRoute 53リゾルバーのパス
VPCにソースENIを作成
多くのVPCで使用可能
1つのエンドポイント = 複数のENI
制限：10,000 QPS pre ENI

Route 53 リゾルバー：リゾルバールール

Route 53 リゾルバーがクエリを作成する方法を構成する
2つのタイプ： FORWARD and SYSTEM

アウトバウンドエンドポイント：複数のVPC

複数のVPCに複数のアウトバウンドエンドポイントが必要か？
- いいえ。ルールを多くのVPCで共有および関連付ける。
VPC/アカウント間でアウトバウンドエンドポイントを共有する必要があるか？
- いいえ。ルールを関連付けるとエンドポイントは暗黙的に共有される。
VPCが異なるAWSアカウントにある場合はどうなるか？
- Resource Access Managerは、リゾルバールールのクロスアカウントを共有。
VPCピアリングまたはTrangsit Gatewayは必要か？
- いいえ

アウトバウンドエンドポイント：ベストプラクティス

高可用性のためにマルチAZで複数のENIを使用
控えめに使用する
ターゲットとして固定IPを維持する
QPSのCloudWatchアラーム

リゾルバールール:どのように機能するか？

重複するルールを作成するとどうなるか？
- 最も具体的な一致ルールが勝つ
- FORWARDが同じドメインのSYSTEMに勝つ

自動定義されたSYSTEMルール

"." にFORWARDルールを作成するとします
これはすべてのVPC DNSおよびPrivare DNSをオーバーライドしますか？
Route 53リゾルバーは、より具体的な「自動検出システムルール」を作成します
VPC DNS
- eu-west-2.compute.internal
- eu-west-2.compute.amazonaws.com
- 10.in-addr.arpa, 168.192.in-addr.arpa,[16-31].172.in-addr.arpa
- VPC CIDR/24のルール
プラーベートDNS
- VPCに関連付けられたすべてのプライベートホストゾーン

リゾルバールールまとめ

最も具体的なルールが勝つ
プライベートDNS、プライベートリンクエンドポイント、およびVPC DNSは自動定義されたルールを取得
- それらはオーバーライド可能
SYSTEMがamazonaws.comを解決できるようにすることがベストプラクティス
逆引くレコードを忘れないように（例:keberos)
VPC CiDR範囲は/24ルールを自動定義
- それらはオーバーライド可能

Route 53 リゾルバー & Active Directory

EC2のActive Directory

AWS Managed Microsoft AD、Simple AD、および自前でインストール
Active Directoryマネージャー、Actice Directoryドメイン上のホストのダイナミックDNS
- フォワードおよびリバースDNSは重要
一般的にはDNSのドメコンを指すようにDHCPを更新する
ドメコンは、Active Directoryドメインと逆引きレコードに回答
ドメコンは通常、他のすべての場合はRoute 53 Resolver（+2）に転送します
DNSフォワーダー（インスタンス）と同様に、このソリューションは多くのユーザに適する
- 問題点／Windowsインスタンスはすべて、DHCPの最初のネームサーバーを照会する傾向がある
- 問題点／スケーリング：VPC+2の1024 ppsの制限が適用される

Route 53リゾルバーとActive Directory

手順

Route 53 Resolverアウトバウンドエンドポイントを作成
リゾルバールールを作成
- Active DirectoryドメインをAWS Managed Microsoft AD DNSアドレスに転送
- VPCサブネットをAWS Managed Microsoft AD DNSアドレスに転送し、各自動検出ルールをオーバーライド
DHCPネームサーバーをAmazonProvidedDNSに戻す

必須条件

Active Directoryドメイン：mydomain.com
VPC CIDR：10.10.0.0/23

Active Directoryの信頼関係

オンプレミスドメインとのActive Directory信頼関係がある場合はどうなるか？
通常、信頼できるデータセンターに直接転送するルールを好む

複数のVPCにわたるDNS管理

多くの場合、大規模な顧客は以下のようなことをしており、DNSを一元管理するのは難しい場合がある

ネットワークとDNSを管理するインフラチーム
多くの開発チーム、複数AWSアカウントとVPC
VPCピアリングまたはTranit Gateway相互接続
ハブとスポークのネットワークアーキテクチャ
一貫性のあるDNSビューの共有

ハブとスポーク戦略

コミュニティには4つの戦略が登場

ハブDNSの管理:DHCP ネームサーバのスポーク変更
ハブDNSの管理:エンドポイントを介してハブにスポーククエリを転送
VPC共有
プライベートホストゾーンとリゾルバルールの共有と関連付け

1.ハブDNSの管理：DHCPの変更

長所
- 使い慣れたモデル（転送インスタンスなど）
短所
- 単一のインバウンドENIでホットスポットを期待する
- フォールトトレラントではない
- ローカルインスタンスキャッシュなし
- 10Kクエリ/秒ENI制限を介したすべてのクエリ
- クエリごとに最大4倍のAZ間ホップ
- スポークとハブ間のL3接続が必要
- より高いクエリコスト

2.エンドポイント経由で転送

プライベートゾーンをハブVPCに関連付ける
ハブVPCのアウトバウンドおよびインバウンドエンドポイント
ルールは、アウトバウンドエンドポイントからインバウンドエンドポイントを介してプライベートホストゾーンのリゾルバーに転送します
オンプレミスに転送される追加のルール
ルールを共有し、スポークVPCに関連付けます
長所
- 簡単なセットアップ/メンテナンス
- VPC+2リゾルバー、キャッシュを使用
- 転送されないクエリはスケーラブルパスを使用します
短所
- 拡張性が低い（1万クエリ/秒の制限：VPC+2の場合は1024 pps）
- 各クエリはアベイラビリティーゾーン間を最大4回横断します
- 耐障害性ほどではない
- クエリ費用

3.VPC共有

長所
- 何百ものVPCは必要ありません
- 1つのVPC、DNSの一貫したビューの保証
- ネットワークの簡素化
短所
- 今日の機能のギャップ
- 開発チームの自律性/分離性の低下

4.共有して関連付ける

VPC間でPrivateLinkエンドポイントを処理するにはどうすればいいか？

エイリアスを使用して共有可能なプライベートホストゾーンを作成する
- ssm.eu-west-2.amazonaws.comというプライベートゾーン
- ssm.eu-west-2.amazonaws.com A（ALIAS）vpce-xx..vpce.amazonaws.com。
長所
- 最も回復力と拡張性
- VPC + 2エンドポイント、ローカルキャッシュ、AZ分離を使用
- 最小転送ホップ
- 低コスト
短所
- PHZ共有は面倒で、CLI / APIのみです
- プライベートホストゾーンごとのVPCアソシエーションの制限

Route 53リゾルバーベストプラクティス

高可用性
- 複数のアベイラビリティーゾーンでリゾルバーENIを常に使用する
転送を控えめに使用する
- EC2インスタンスにAmazonProvidedDNSを使用する
- プライベートホストゾーン/ルールをすべてのVPCに関連付けることを好む
- 可能な場合、クエリをローカルのアベイラビリティーゾーン内に保持する
モニタリング
- リゾルバーエンドポイントのQPS制限に近づいていないかCloudWatchアラームを設定する